Subject: FW: Flow Control curve ball...

From: Paul Brittain <[email-masked]>
Date: Fri, 16 Dec 94 09:15:00 GMT

Pandian,

Thanks for the feedback.  I have included comments below.

I was not clear from your note whether you think this is a topic we should 
consider for V1, but would be interested to hear your opinion - and anyone 
else's!

Paul Brittain
Data Connection.

 ----------
>From: aiw-dall
>To: pjb
>Subject: Re: Flow Control curve ball...
>Date: Wednesday, December 14, 1994 7:43PM
>
>---------------------------------------------------------------------------  
 ---
>Hi Paul,
>I just want to bring to your attention the following issues to understand
>this a little further and explore the ramifications it has on the
>rest of the ckt setup logic.
>        - I think IPM flies with an INFO header(16 bytes).
>          And as we all know it is not enough to resolve the circuit id.
>          The first IPM cannot flow until the ckt is established
>          or we need to change IPM to carry the CONTROL header (76 bytes)

True, but I don't think this is a problem as DGRMFRAME and INFOFRAME 
messages also can't flow until the circuit is established.

>        - Every ckt init would generate an additional IPM
>          in both directions to just exchange the inital grants.
>          That is 2 additional frames for every ckt init,
>          which is not bad.

Like you, I don't think this is a major performance issue as it only occurs 
when the circuit is set up.  It is the penalty to be paid for achieving 
clean functional separation of Flow Control.

>        - We need to be able to accomodate more than a few
>          XID exchanges to happen without an additional
>          IPM. This mandates that the default initial
>          window size to be atleast > no of frames
>                                      to establish ckt +
>                                      no of possible XID frames.
>

According to section 8.1, the only frames that are subject to flow control 
are the INFOFRAME and DGRMFRAME messages that can only flow once the circuit 
is established.  I think, therefore, that the XID frames (and anything else) 
used in _connnection_ (N.B _not_ circuit) setup are not subject to the 
initial pacing window.

(Shannon - if I have misunderstood the intent of the flow control mechanism 
on this point, please post a correction)

>        /pandian
>
>>
>>
>> A very last minute thought on Flow Control...
>>
>> Currently the Flow Control flags may be piggy-backed on almost all 
message
>> types, not just on INFOFRAME or DGRMFRAME messages.  This has the
>> unfortunate effect of making it difficult to architect a separate 'data
>> forwarder process' for each circuit that handles only the golden path 
data
>> traffic as it cannot have sole responsibility for Flow Control.
>>
>> I'll confess an interest in this - we do have such a data forwarder and
>> would like to be able to achieve the clean functional separation of 
putting
>> all Flow Control responsibility in this process.  I don't believe this
>would
>> be a performance problem even though it would mean that the grant of the
>> initial window would flow as an independent flow control message.  Once
>into
>> data flow (I or UI frames) there would be no difference to the Flow 
Control
>> mechanism.
>>
>> We believe this would be a significant improvement on the architectural
>> cleanliness of DLSw, but recognise that it is very much a last minute
>> thought for V1 (though it actually requires only relatively little change
>to
>> the document - basically just change the list of permitted frames for 
Flow
>> Control piggybacking and mandate that a RESTART_DL implies either a Reset 

>> Window or reverts to the initial state).
>>
>> Is there any interest in doing this for V1 (I'm willing to do the
>> appropriate wordsmithing for Alan), or should we consider it in V2 
instead?
>>
>> Paul Brittain
>> Data Connection
>>
>
>
>--
>G. Pandian                      + Gnanaprakasam Pandian      +
>Cisco Systems, Inc.             + Software Engineer          +
>190, W. Tasman Drive, Bldg E    + Phone : (408)526-7684      +
>San Jose                        + FAX   : (408)526-8959      +
>CA 95134                        + E-mail: [email-masked] +
>
>
>